This definition does not consider composition of types:

use std::mem::MaybeUninit;

union Uninit32 {
    u: u32,
    i: i32,
    f: f32,
    void: (),
}

struct Newtype32(Uninit32);

fn main() {
    let x: Newtype32 = unsafe { MaybeUninit::uninit().assume_init() };
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=feae8c987fa0b2703533ce0ebf8b23ba

This passes miri because all the bytes in Newtype32 are defined by Uninit32, which is allowed to be uninitialized.

When bytes are read as a type (e.g. by using ptr.read(), *ptr, or mem::transmute), a "typed read" occurs. This asserts the bytes are valid as that type. Uninit32 and MaybeUninit are the same thing here: unions with () as a possibility, which means they must be valid to read from a blob of uninitialized bytes within a valid allocation¹. Because Newtype32 is entirely defined by Uninit32, it is also valid to read from uninitialized bytes: the struct wrapper does not impose a novel validity requirement. If this is a mandatory guideline, it should be more exacting about why.

resolved

You got this right, but the lesson needs to be extended elsewhere: assume_init and the read of a union field at its type are not really different operations in the semantics, so why would u32 be valid to read from a union field?

Got it!

resolved

I don't know if you want to fully list all validity requirements here, but references also need to point to valid memory.

This code has UB:

fn main() {
    let mut uninit: MaybeUninit<&u8> = MaybeUninit::uninit();
    unsafe {
        // write non-null and aligned address.
        (&raw mut uninit).cast::<*const u8>().write(ptr::dangling());
        // UB here
        let init = uninit.assume_init();
    }
}

add this requirement and created a new noncompliant example

resolved

Or maybe something that the reference is not dereferencable. (because the memory it points to doesn't exist)